Reason for Proposed Changes

• Currently there is no query to ensure that there is a "azurerm_monitor_activity_log_alert" resource configured to capture "Service Health" events.

• Quoting CIS_Microsoft_Azure_Foundations_Benchmark_v5.0.0 page 267: "Monitoring for Service Health events provides insight into service issues, planned maintenance, security advisories, and other changes that may affect the Azure services and regions in use."

• Through the CIS benchmark we can also determine that detecting the target configuration boils down to checking 4 conditions :

  • The "scopes" field should target a subscription.
  • The category field should be set to "ServiceHealth"
  • In the "events" array, "Incident" should be included
  • Finally it must be ensured that the "action_group_id" field is set (inside an "action" block).

• It is expected that all "subscriptions" are associated in this manner, the data block "azurerm_subscription" allows defining these subscriptions, and so the query should iteratively check all associated alert logs for each subscription.

Proposed Changes

• Implemented the missing query.

• The query will start by collecting all log alert type resources as well as all subscriptions defined through data azurerm_subscription blocks.

• Then, for each subscription, the log alerts are scrubbed to search for at least one that fulfills requisites 2, 3 and 4 and references the specific subscription the auxiliary function "at_least_one_valid_log_alert" got called for.

• The query will trigger differently depending on the log_alerts found, with the following priority :

  • Flag for the "action_group_id" not being set
  • Flag if the "events" array does not include "Incident"
  • Flag if the "category" is set to a value that is not "ServiceHealth"
  • Flag the subscription itself if there is not a single log alert resource associated with it.

• These priorities are demonstrated through the positive4 and positive5 tests and their results.

I submit this contribution under the Apache-2.0 license.